前言
昨天透過 A/B 測試比較了不同配置的整體分數，但整體分數只能告訴我們「平均表現」，沒辦法告訴我們「哪些具體問題還沒解決」。今天要換一個更細緻的角度：深入分析個別的錯誤案例，找出系統性的問題模式。
為什麼整體分數不夠？
假設 Context Recall 平均分數是 85%，聽起來已經不錯，但這 15% 沒被涵蓋到的案例，可能集中在某一種特定類型的問題上（例如所有跟「比較兩個項目」有關的問題都表現不好），而不是均勻分散。只看平均分數，會讓這種系統性的弱點被掩蓋掉。
建立錯誤案例分析的流程
Step 1：篩選出低分案例
def find_low_score_cases(eval_results, threshold=0.6):
return [
r for r in eval_results
if r["faithfulness"] < threshold or r["context_recall"] < threshold
]
​
Step 2：對每個低分案例做歸因
針對每一個低分案例，人工檢視並標記問題屬於哪個類別：
案例
問題類別
說明
案例 1
檢索失敗
相關內容根本沒被檢索到
案例 2
Chunking 問題
答案被切分邏輯拆成兩半
案例 3
生成幻覺
檢索到正確內容，但模型還是編造了額外細節
案例 4
問題模糊
使用者問題本身表達不清楚，難以判斷真正意圖
案例 5
知識庫缺口
知識庫中根本沒有這個問題的答案
Step 3：統計問題類別的分布
把所有低分案例分類完成後，統計每個類別的數量與佔比，找出最需要優先解決的問題：
檢索失敗：40% ← 優先處理，考慮加強 Rerank 或調整 Chunk Size
生成幻覺：25% ← 加強 Prompt 規則
Chunking 問題：20% ← 回頭調整切分策略
問題模糊：10% ← 導入 Query Rewriting
知識庫缺口：5% ← 補充知識庫內容
​
這種分類統計能幫助團隊把有限的優化心力，投注在影響最大的問題上，而不是東修一點西修一點。
建立「回歸測試」機制
每次針對某類問題做了優化後，建議：
把當初發現問題的案例，加進固定的測試集裡
之後每次調整系統，都重新跑一次這個測試集，確保「修好的問題沒有再度出現」（這就是軟體工程中常見的回歸測試概念，應用在 RAG 系統的迭代上）
regression_test_set = load_known_problem_cases() # 累積下來的已知問題案例集

def run_regression_test(rag_system):
results = run_evaluation(regression_test_set, rag_system)
failed = [r for r in results if r["faithfulness"] < 0.7]
if failed:
print(f"警告：{len(failed)} 個已知問題案例又出現退步！")
return results
​
迭代優化的節奏
一個實務上可行的迭代循環：
跑評估 → 篩選低分案例 → 歸因分類 → 挑選影響最大的問題優先處理
↑ │
└──────────────── 調整系統、加入回歸測試 ←────────────┘
​
不需要期待一次優化就能解決所有問題，RAG 系統的品質提升本來就是一個持續迭代的過程。
小結
比起只看整體分數，深入分析錯誤案例、找出系統性的問題模式，能讓優化工作更有方向性。搭配回歸測試機制，也能確保每一次的修正是真正的進步，而不是「修好一個、壞掉另一個」。到這裡，生成與評估系列告一段落，明天開始我們要進入最後的落地部署階段。